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WIM primitives for handling the Secure Socket Layer protocol (SSL) 
1 Field of the Inve ntion 

The Wireless Application Protocol (WAP) defines an industry-wide 
5 specification for developing applications that operate over wireless 
communication networks. The scope for the WAP Forum is to define a set 
of specifications to be used by service applications. The wireless market is 
growing very quickly, and reaching new customers and services. To 
enable operators and manufacturers to meet the challenges in advanced 
10 services, differentiation and fast/flexible service creation WAP Forum 
defines a set of protocols in transport, security, transaction, session and 
application layers. 

The Security layer protocols in the WAP architecture can be the Wireless 
Transport Layer Security (WTLS) or the standard Transport Layer Security 

15 (TLS) Internet protocol. WTLS provides functionality similar to TLS 1.0 but 
is more adapted to lower bandwidth communication channels. TLS and 
WTLS layer operate above the transport protocol layer. They provide the 
upper-level layer of WAP with a secure transport service interface and also 
provide an interface for managing (eg. creating and terminating) secure 

20 connections. The primary goal of the WTLS or TLS layers is to provide 
privacy, data integrity and authentication between two communicating 
applications. 

For optimum security, some parts of the security functionality need to be 
25 performed by a tamper-resistant device, so that an attacker cannot retrieve 
sensitive data. Such data is especially the permanent private keys used in 
the WTLS or TLS handshakes with client authentication, and for making 
application level electronic signatures (such as confirming an application 
level transaction). In WTLS, also the master secrets, protecting secure 
30 sessions are relatively long living - which could be several days. This is in 
order to avoid frequent full handshakes which are relatively heavy both 
computationally and due to large data transfer. Master secrets are also 
used as a source of entropy, to calculate MAC keys and message 
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encryption keys, which are used to secure a limited number of messages, 
depending on usage of WTLS or TLS. 

The WAP Identity Module (WIM) Is used In performing WTLS, TLS and 
application level security functions, and especially, to store and process 

5 information needed for user identification and authentication. The WIM 
stores the client sensitive data, especially keys and sessions master 

secretsT-Alr-op eia l ions w heTe-keys-and-m aste r sec rets-are-tnvolved-afe^ 

performed internally in the WIM. An example of a WIM implementation is a 
smart card. In the phone, It can bs the Subscriber Identity Module (SIM) 

10 card or an external smart card. 

2, Rctpr M 

The WIM (WAP Identity Module) is a security token standardized in the 
WAP Forum. As mentioned above, the WAP Forum WIM specification 

is describes how the WIM is used with TLS and WTLS and in application 
level services. The WIM specification does not specify service primitive for 
SSL (Secure Socket Layer), which is another type of Transport Layer 
Security protocol. In fact, TLS is derived from SSL and the protocols are 
quite similar, but some differences exist. This invention deals with adding 

20 an efficient support in the WIM for SSL. 



3 What problem needs to be solved? 

In WTLS and TLS the Mobile Equipment (ME) sends to the server a 
25 message called "Finished" message, which is always sent at the end of the 
handshake to verify that the key exchange and authentication processes 
were successful. 

The Mobile Equipment (ME) uses the WIM for calculating the data to send 
30 in the "Finished" message and also tho data that should be received from 
the server. In order to do that it issues the "Client Finished Check" and 
"Server Finished Check" commands to the WIM. Using the PRF (Pseudo 
Random Function), the WIM calculates a requested number of bytes 
based on the session master secret, and a seed value received from the 
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ME. The WIM then returns the bytes to be used by the ME in the "Finished" 
message. For calculating the Client Finished Check data the ME uses the 
WIM-PHash primitive with the following input data parameter: 
"client finished" + Hash(handshake_messages). The primitive then returns 
5 the needed data block. 

For Calculating the server finished check the ME uses the WIM-PHash 
primitive with the following input data parameter: "server finished" + 
Hash(handshake_messages). The primitive then returns the needed data 
10 block. 

The u Hash(handshake_messages)" is defined as the SHA-1 and/or MD5 
hash (depending on protocol) of the concatenation of all previous 
handshake messages that were exchanged up to but not including the 
is "Finished" message. 

In SSL the parameters that are sent to the WIM for the "Finished" message 
are a bit different. When we perform the finished check In SSL, it is 
necessary to perform a hash on 'handshake_messages + Sender + 

20 master_secret + padV. Comparing with WTLS and TLS we see that the 
Hash should be calculated also over the session "master secret" in 
addition to "handshake_messages". This poses a problem since the ME 
does not know the value of the master secret as it is securely stored in the 
WIM and is never exposed externally. If the ME could compute the hash 

25 over 'handshake_messages' In WTLS and TLS and then send it as a 
parameter to the WIM-PHash primitive, it is now unable to calculate the 
conesponding parameter in SSL. One simple solution is to first store the 
"handshake_messages" data block in the WIM and then ask it to calculate 
the Hash by internally adding the master secret to the data block before 

30 computing the hash. This solution has several drawbacks: 

• The "handshake__messages" data block is rather large and a big 
storage area should be allocated in the WIM 

• It is time consuming to send all the "handshake_measages" data to 
store in the WIM 
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• It is time consuming to calculate the Hash in the WIM since the ME 
can usually do it faster as It has a stronger processor 

The above drawbacks call for a different solution, which is described in this 
5 invention. This invention defines a solution for calculating the "Finished" 

message by the WIM module for SSL In an efficient manner and without 
the need to send the who le "h^n^sira1<e~m~es^ alorerhT 

the WIM. 



10 4 Invention 

The Invention is a method for calculating hashing of a message In a device 
communicating with a smart card, said device and said smart card storing 
the same hash function, the message comprising data blocks including 
secret data and other data, secret data being only known by the smart 

15 card, characterized in that the calculation of the hash of the secret data is 
performed in the smart card and the calculation of the hash of all or part of 
the other data is performed in the device, and in that, the intermediate 
result is transmitted from the device to the card, or Inversely, depending on 
whether the hash calculation of the hash of a data has to be performed by 

20 the smart card or the device. 



5 Detailed Descrlotion o f E xamples Illustrating t he Invention. 
In order to simplify the description, the same elements illustrated in the 
25 drawings have the same references. 

Fig. 1 represents an example of a data processing system S in which the 
invention may be applied. 

Figures 2-4 are views of a message including secret data. 

30 

Figure 1 represents a system S. In our example, This system includes a 
smart card CAR coupled to a device ME communicating with a server 
SERV through a network RES. 
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In order to avoid the drawbacks that were described before we can 
leverage on. the characteristics of the Hash function. This function works 
on a fixed length of data Input and the result is carried on to the next 
iteration. It calculate a hash on the first block of the data (64 bytes for 
SHA-1), then carry the result to the calculation of the Hash on the second 
block and continue like that until ail input data is consumed. In our case 
the input data is: 

, handshake_messages + Sender + master_secret + pad1\ where the 
operator means concatenation. 



The ME can start calculating the hash over the "handshake_messages" 
which is the biggest data block. It then send the intermediate result and the 
remaining data in the last data block, to the WIM and the WIM continue the 
hash calculation internally by using the intermediate result, remaining data 
15 in the last data block and the additional data that is kept internally (e.g. 
"master^secret''). 

The main advantage of the above solution is speed. It will take more time 
to write the whole data In a file in the WIM and then have the WIM read it 
20 and hash it. Speed is_very Important in the handshake and it is very 
important to optimize it. If it takes more than a few seconds to establish a 
secure session it is not very convenient for the user. The other advanteo! 

impfemen, oecepKlnee * env,ronme " t «■ 

~» «*• tSzzzz ITT —* 

«»ung rne pso command for calculating 
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the "Finished" message. This is natural, easy to implement and fit well the 
WIM specification approach. 



5 The invention is a method for implementing support in the WIM for 
calculating the "Finished" message in SSI wher e^the-ME-start-calculatini 



the hash over the "handshake_messages" and then send the intermediate 
result to the WIM that continue the hash calculation internally by using the 
intermediate result and the additional data that is kept internally (e.g. 
io "master_secret") 

Advantageously, where the intermediate result of the hash calculation 
done by the ME is sent to the WIM by using the WIM MSE-Set command 
that set the value in a relevant placeholder in an SSL Security Environment 
15 in WIM. 

Generally, the Invention is a method for calculating hashing of a message 
(FM) ,n a device communicating with a smart card, said device and said 
smart card storing the same hash function, the message comprising data 

IT '"T 9 secret date (SD1) and o " a 

- device, and In that, * """" * 

5 device to the cord or ln V ^, m ( } transmrtte d from the 

nas to oe performed by the smart card or the device. 

Intermediate result (ft, to L ,LT^„^" —* *• ^spending 

«*. me -mermed Lte reTuVl? and *" * 

-ample, the data SDC ,^1*L * ^"i" 9 da,a <">')• 

" K! ' U< * n9 da * <• "ashed In the smarteard. 
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On the contrary, If data (PD1) is followed by the other data (SD1) (see 
figure 3), the (ME) starts calculating the hash of (PD1) and then send the 
corresponding intermediate result (R) and remaining part RP of last hash 
block to the smart card that continue to do the hash calculation internally 
5 by using the intermediate result (R), last hash block and the remaining 
data (SD1). 

in our example, the device Is implementing the Transport Layer Security 
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Claims: 

1. A method for calculating hashing of a message (FM) in a device 
communicating with a smart card, said device and said smart card 
storing the same hash function, the message comprising data 

toeks-Hncluding-secre t data ( SPI^^d-otheTHfetanfPOl), secret' 
data (SD1) being only known by the smart card, characterized in 
that the calculation of the hash of the secret data (SD1) is 
performed in the smart card and the calculation of the hash of ail or 
part of the other data (PD1) is performed in the device, and in that 
the Intermediate result (R) is transmitted from the device to the card, 
or inversely, depending on whether the hash calculation of the hash 
of a data has to be performed by the smart card or the device. 

2. The method according to claim 1, characterized in that, if data 
(SD1) is followed by the other data (PD1) in the message (FM), the 
smart card starts calculating the hash of all blocks that include a 
secret data (S01) and then sends the corresponding intermediate 
result (R) to the (ME) that continue the hash calculation by using the 
intermediate result (R) and the remaining data (PD1). 

3. The method according to claim 2, characterized in that, if a block 
includes a part comprising secret data (SD1) and another part 
comprising other data (PD1), the smart card calculates the hash of 
this block. 



4. The method according to claim 1, characterized in that, if data 
(PD1) is followed by the other data (SD1), the (ME) starts 
calculating the hash of (PD1) and then send the corresponding 
intermediate result (R) and remaining part (RP) of last hash block to 
the smart card that continue to do the hash calculation internally by 
using the intermediate result (R), last hash block and the remaining 
data (SD1). 



Fax resu de : 33 1 4V 4b 




&OHLUn0£JU»£Jl 



m 



W 03/ Ui. 



9 



5 6. 



7. 

10 



The method according to claim 1, characterized in that the device is 
Implementing the Transport Layer Security protocol is SSL (Secure 
Socket Layer). 

The method according to claim 5, characterized in that the message 
is a message called "Finished 1 ' in the SSL protocol and In that the 
secret data (SD1) is an SSL session master secret. 

The method according to claim 1, characterized in that the smart 
card is a WAP Identity Module (WIM). 



Fax regu de : 33 1 47 



26 SCHLUMBEKGER 

10 



84/BS/02 Ifc'bJJ p s 



Abstract 

The invention Is a method for calculating hashing of a message in a device 
communicating with a smart card, said device and said smart card storing 
s the same hash function, the message comprising data blocks including 
secret «M*> ot h er rt * tft , seccat data being nnly knnwn hv the smatt- 
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card, characterized in that the calculation of the hash of the secret data is 
performed in the smart card and the calculation of the hash of ail or part of 
the other data is performed in the device, and in mat, the intermediate 
result is transmitted from the device to the card, or inversely, depending on 
whether the hash calculation of the hash of a data has to be performed by 
the smart card or the device. 
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